Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/000132_misckit-reques…aska.et.byu.edu_Thu Feb 17 03:08:10 1994.msg

Internet Message Format | 1994-10-30 | 5KB

Return-Path: <[e-mail]>
Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
    id AA00356; Thu, 17 Feb 94 03:05:09 -0700
Received: from darth.byu.edu by alaska.et.byu.edu; Thu, 17 Feb 1994 03:02:13 -0700
Received: by darth.byu.edu (NX5.67d/NX3.0M)
    id AA00335; Thu, 17 Feb 94 03:00:43 -0700
Date: Thu, 17 Feb 94 03:00:43 -0700
From: Don Yacktman <[e-mail]>
Message-Id: <[e-mail]>
Received: by NeXT.Mailer (1.100.RR)
Received: by NeXT Mailer (1.100.RR)
To: [e-mail]
Subject: Re: Breaking MiscKit into separate "levels" (WAS Re: MiscStringKit?)
Reply-To: [e-mail]


Robert Nicholson:
> > Don's and the authors work on the MiscKit are exceptional.  However,
> > I don't have a need for all of the functionality that exists
> > within misckit.a. I'm sure there are other people in the same boat.

OK, I'm seeing two ways to split things up.  One is into smaller libs
with specific functionality in each.  I'm somewhat against this, especially
when things start to depend on each other's existence.  (Like, the log and
lock files _require_ the string class...)  But I also understand why you
wouldn't want all the extra junk linked into your app.  If NeXT would let
us make shlibs, this would be a moot point.  After all, you link NeXT
apps against the whole AppKit.  Since it is shared code, it doesn't really
matter much except for the size of the debug executable.

The other option I am seeing is to split up by levels, as Ernie P. suggests:

> This brings up something I have thought about before.  I was
> wondering if it would be possible to break the kit apart into
> "levels" depending on how much it relied on other things:
> [...level 0, 1, 2...]

I see these, then, as:  (Ernie's classification, my re-phrasing)
0)  Depends on Object, standard C headers, and other level 0 classes.
1)  Depends on NeXT's "common classes" like List and HashTable,
    anything that level 0 depends on, and level 1 classes.
2)  Depends on everything in levels 0 and 1, other level 2 classes, and
    the NeXT appkit.

Well, I like this idea.  It might be a good way to go.  The question is then
how we set up the libraries; do we make level 2 mean that the .a file has
all of level 1 and level 0 in a single file, or do we make each level's
.a file separate, and then to use the level 2 lib you have to link against
the level 0 and level 1 lib?  Remember my whole point in creating the
MiscKit initially was to stick in a bunch of objects I use a lot so that I
could add one file -- the .a file -- in project builder and then I'm on my
way.  It's makes things so much more comfy for the lazy.  :-)

So I guess if disk space is no issue, the first option is the one the lazy
person in me likes.  However, it's not much work to add a few libs to
the project.  So since my disk space is at a premium, I think I'd in
reality prefer the second option.  I don't think that this would be too
terribly difficult to maintain, either.

Michael Pizolato's division is even finer-grained; I'm afraid that if
we break things up too far that it will make the MiscKit too confusing
to work with...but I think either scheme suggested would be pretty useful.
How do people prefer to split things up?  We could do a hybrid:

0) C functions and macros only
1) depends on Object, too
2) depends on common classes
3) depends on appkit
4) adds palette support

Because of the way palettes are done, (4) might not be really necessary.
And perhapd the IB methods should only be present as a category in the
palette project, and not in the library itself anyway.  (cf. MiscString)  Does
anybody use the IB methods to get info about an object other than from IB?
If not, then maybe placing this in the palette projects would be best.

> The build process could produce either "misckit[012]" or just "misckit",
> or both, depending on flags (that's not asking too much, is it?).

I'd need a to learn a little more about Makefiles in order to do it this way,
but it shouldn't be too horrid, I think.

Then there's header organization...perhaps make four headers:
<misckit/level0.h>, <misckit/level1.h>, <misckit/level2.h>, and
<misckit/misckit.h>.  The last one just includes all of them; and
the level[12].h would include the lower numbered headers.

> The relevance of this to Robert's comments it that String and
> similar non-dependant classes could become part of a
> 'lightweight' Level 0 class.  It also addresses the question
> (in one of the newsgroups, I think) about what portions of
> the MiscKit are applicable to non-NeXT platforms.

I think that such a scheme would answer those questions, and
provide useful objects for non-NeXT folks.  I think that would be
a good thing.  And right now, the AppKit is pretty much intertwined
throughout the MiscKit.

Now, there is an important thing to note:  The NeXT and GNU Object
classes _are_ slightly different; there are object methods in the GNU
and in Cox's book that are not in NeXT's object class.  Things like
deep/shallow copies, etc.  Perhaps we need a category for NeXT
folk to extend things so that we are building on common ground.
That's some food for thought...

Oh, and suggested, we'd be better off using mnemonics than level
numbers.  Any suggestions here?

---
Later,

-Don Yacktman
[e-mail]